Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/security/log_tcp_6.0alpha.shar/README

Text File | 1993-07-02 | 35.6 KB | 787 lines

@(#) README 1.11 93/07/02 16:33:20

Table of contents
-----------------

    1 - Introduction
    2 - Disclaimer
    3 - Tutorials
        3.1 - How it works
        3.2 - Where the logging information goes
    4 - Features
        4.1 - Access control
        4.2 - Host name spoofing
        4.3 - Host address spoofing
        4.4 - Remote username lookups
        4.5 - Language extension hooks
    5 - Other works
        5.1 - Related documents
        5.2 - Related software
    6 - Limitations
        6.1 - Known wrapper limitations
        6.2 - Known system software bugs
    7 - Configuration and installation
        7.1 - Easy configuration and installation
        7.2 - Advanced configuration and installation
        7.3 - Daemons with arbitrary path names
        7.4 - Building and testing the access control rules
        7.5 - Other applications
    8 - Acknowledgements

1 - Introduction
----------------

With this package you can monitor incoming connections to the SYSTAT,
FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other network
services.

It supports both 4.3BSD-style sockets and System V.4-style TLI. Praise
yourself lucky if you don't know what that means.

The package provides tiny daemon wrapper programs that can be installed
without any changes to existing software or to existing configuration
files.  The wrappers report the name of the remote host and of the
requested service; the wrappers do not exchange information with the
remote client process, and impose no overhead on the actual
communication between the client and server applications.

Optional features are: access control to restrict what systems can
connect to your network daemons; remote user name lookups with the RFC
931 protocol; additional protection against hosts that pretend to have
someone elses host name; additional protection against hosts that
pretend to have someone elses host address.

Early versions of the programs were tested with Ultrix >= 2.2, with
SunOS >= 3.4 and ISC 2.2. Later versions have been installed on a wide
variety of platforms such as SunOS 4.x and 5.x, Ultrix 3.x and 4.x, DEC
OSF/1 T1.2-2, HP-UX 8.x, AIX 3.1.5, Apollo SR10.3.5, Sony, NeXT, SCO
UNIX, DG/UX, Cray, and an unknown number of other ones.

Requirements are that the network daemons are spawned by a super server
such as the inetd; a 4.3BSD-style socket programming interface and/or
System V.4-style TLI programming interface; and the availability of a
syslog(3) library and of a syslogd(8) daemon.  The wrappers should run
without modification on any system that satisfies these requirements.
Workarounds have been implemented for several common bugs in systems
software.

What to do if this is your first encounter with the wrapper programs:
1) read the tutorial sections for an introduction to the relevant
concepts and terminology; 2) glance over the security feature sections
in this document; 3) follow the installation instructions (easy or
advanced). I recommend that you first use the default security feature
settings.  Run the wrappers for a few days to become familiar with
their logs, before doing anything drastic such as cutting off access or
installing booby traps.

2 - Disclaimer
--------------

The wrapper programs rely on source address information obtained from
network packets. Such information is not 100 percent reliable, although
the wrappers do their best to expose forgeries.

In the absence of cryptographic protection of message contents, and of
cryptographic authentication of message originators, all data from the
network should be treated with sound scepticism.

THIS RESTRICTION IS BY NO MEANS SPECIFIC TO THE TCP/IP PROTOCOLS.

3 - Tutorials
-------------

The tutorial sections give a gentle introduction to the operation of
the wrapper programs, and introduce some of the terminology that is
used in the remainder of the document: client, server, the inetd and
syslogd daemons, and their configuration files.

3.1 - How it works
------------------

Almost every application of the TCP/IP protocols is based on a client-
server model. For example, when a user invokes the telnet command to
connect to one of your systems, a telnet server process is executed on
the target host. The telnet server process connects the user to a login
process. A few examples of client and server programs are shown in the
table below:

              client   server    application
              --------------------------------
              telnet   telnetd   remote login
              ftp      ftpd      file transfer
              finger   fingerd   show users

The usual approach is to run one single daemon process that waits for
all kinds of incoming network connections. Whenever a connection is
established, this daemon (usually called inetd) runs the appropriate
server program and goes back to sleep, waiting for other connections.

The wrapper programs rely on a simple, but powerful mechanism.  Instead
of directly running the desired server program, the inetd is tricked
into running a small wrapper program. The wrapper logs the remote host
name or address and performs some additional checks.  When all is well,
the wrapper executes the desired server program and goes away.

The wrapper programs have no interaction with the remote user (or
client process).  This has two major advantages: 1) the wrappers are
application-independent, so that the same program can protect many
kinds of network services; 2) no interaction also means that the
wrappers are invisible from outside (at least for regular users).

Another important property is that the wrapper programs are active only
when the initial contact between client and server is established. Once
a wrapper has done its work there is no overhead on the client-server
communication.

The simple mechanism has one major drawback: since the wrappers go away
after the initial contact between client and server processes, the
wrappers are of little use with network daemons that service more than
one client.  The wrappers would only see the first client attempt to
contact such a server. The NFS mount daemon is a typical example of
a daemon that services requests from multiple clients.

There are two ways to use the wrapper programs:

1) The easy way: move network daemons to some other directory and fill
   the resulting holes with copies of the wrapper programs.  This
   approach involves no changes to configuration files, so there is
   very little risk of breaking things.

2) The advanced way: leave the network daemons alone and modify the
   inetd configuration file.  For example, an entry such as:

     tftp  dgram  udp  wait  root  /usr/etc/tcpd  in.tftpd -s /tftpboot

   When a tftp request arrives, inetd will run the wrapper program
   (tcpd) with a process name `in.tftpd'.  This is the name that the
   wrapper will use when logging the request and when scanning the
   optional access control tables.  `in.tftpd' is also the name of the
   server program that the wrapper will attempt to run when all is
   well.  Any arguments (`-s /tftpboot' in this particular example) are
   transparently passed on to the server program.

For an account of the history of the wrapper programs, with real-life
examples, see the section below on related documents.

3.2 - Where the logging information goes
----------------------------------------

The wrapper programs send their logging information to the syslog
daemon (syslogd). The disposition of the wrapper logs is determined by
the syslog configuration file (usually /etc/syslog.conf). Messages are
written to files, to the console, or are forwarded to a @loghost.

Older syslog implementations (still found on Ultrix systems) only
support priority levels ranging from 9 (debug-level messages) to 0
(alerts). All logging information of the same priority level (or more
urgent) is written to the same destination.  In the syslog.conf file,
priority levels are specified in numerical form.  For example,

    8/usr/spool/mqueue/syslog

causes all messages with priority 8 (informational messages), and
anything that is more urgent, to be appended to the file
/usr/spool/mqueue/syslog.

Newer syslog implementations support message classes in addition to
priority levels.  Examples of message classes are: mail, daemon, auth
and news. In the syslog.conf file, priority levels are specified with
symbolic names: debug, info, notice, ..., emerg. For example,

    mail.debug            /var/log/syslog

causes all messages of class mail with priority debug (or more urgent)
to be appended to the /var/log/syslog file.

By default, the wrapper logs go to the same place as the transaction
logs of the sendmail daemon. The disposition can be changed by editing
the Makefile and/or the syslog.conf file. Send a `kill -HUP' to the
syslogd after changing its configuration file. Remember that syslogd,
just like sendmail, insists on one or more TABs between the left-hand
side and the right-hand side expressions in its configuration file.

4 - Features
------------

4.1 - Access control
--------------------

When compiled with -DHOSTS_ACCESS, the wrapper programs support a
simple form of access control.  Access can be controlled per host, per
service, or combinations thereof. The software provides hooks for the
execution of shell commands when an access control rule fires; this
feature may be used to install "booby traps".  For details, see the
hosts_access.5 manual page, which is in `nroff -man' format. A later
section describes how you can test your access control rules.

Access control is enabled by default. It can be turned off by editing
the Makefile, or by providing no access control tables. The install
instructions below describe the Makefile editing process.

When TCP/IP or UDP/IP is used underneath TLI, the wrapper programs
provide the same functions as with socket-based applications. When some
other protocol is used underneath TLI, the host address will be some
universal magic cookie that may not be usable for access control
purposes.

4.2 - Host name spoofing
------------------------

With some network applications, such as RSH or RLOGIN, the remote host
name plays an important role in the authentication process. Host name
information can be reliable when lookups are done from a _local_ hosts
table, provided that the client IP address can be trusted.

With _distributed_ name services, authentication schemes that rely on
host names become more problematic. The security of your system now may
depend on some far-away DNS (domain name server) outside your own
control. Paradoxically, running NIS (YP) can actually improve hostname
security because it provides you with the equivalent of a local hosts
file.

The wrapper programs verify the remote host name that is returned by
the address->name DNS server, by asking for a second opinion.  To this
end, the programs look at the name and addresses that are returned by
the name->address DNS server. If any discrepancies are found, the
wrappers conclude that at least one of the two name servers is lying,
and assume that they are dealing with a host that pretends to have
someone elses host name.

When the wrappers are unable to verify the remote host name (the
address->name lookup succeeds but the name->address lookup fails), they
also assume that the host name is wrong.

When the remote host name is unavailable (the address->name lookup
fails) the wrappers just use the remote host address when logging the
connection and when consulting the optional access control tables.

When the sources are compiled with -DPARANOID, the wrappers will drop
the connection in case of a host name/address mismatch. When the
sources are not compiled with -DPARANOID, the wrappers just pretend
that the host name is unknown when logging the connection and when
consulting the optional access control tables.

Paranoid mode is enabled by default. It can be turned off by editing
the Makefile. The configuration and installation below describes the
Makefile editing process.

4.3 - Host address spoofing
---------------------------

While host name spoofing can be found out by asking a second opinion,
it is much harder to find out that a host claims to have someone elses
network address. And since host names are deduced from network
addresses, address spoofing is at least as effective as name spoofing.

The wrapper programs can give additional protection against hosts that
claim to have an address that lies outside their own network.  For
example, some far-away host that claims to be a trusted host within
your own network. Such things are possible even while the impersonated
system is up and running.

This additional protection is not an invention of my own; it has been
present for at least five years in the BSD rsh and rlogin daemons.
Unfortunately, that feature was added *after* 4.3 BSD came out, so that
very few, if any, UNIX vendors have adopted it.  Our site, and many
other ones, has been running these enhanced daemons for several years,
and without any ill effects.

When the programs are compiled with -DKILL_IP_OPTIONS, source routing
will be disabled for all TCP connections that are handled by the
wrapper programs.

All this cannot be used with SunOS 4.x because of a kernel bug in the
implementation of the getsockopt() system call. Kernel panics have been
reported for SunOS 4.1.1 and SunOS 4.1.2. The symptoms are "BAD TRAP"
and "Data fault" while executing the tcp_ctloutput() kernel function.

The feature is disabled by default. It can be turned on by editing the
Makefile.  The configuration and installation section below describes
the Makefile editing process.

UDP services do not benefit from this additional protection. With UDP,
all you can be certain of is the network packet's destination address.

4.4 - Remote username lookups
-----------------------------

The protocol proposed in RFC 931 provides a means to get the remote
user name from the client host.  The requirement is that the client
host runs an RFC 931-compliant daemon. The information provided by such
a daemon is not intended to be used for authentication purposes, but it
can provide additional information about the owner of a TCP connection.

Remote user name lookups are enabled when the wrappers are compiled
with -DRFC931.  There are some limitations: the number of hosts that
run an RFC 931 (or compatible) daemon is small (but growing); remote
user name lookups do not work for datagram (UDP) connections. More
seriously, remote user name lookups can cause noticeable delays with
connections from non-UNIX PCs. The wrappers use a 30-second timeout for
RFC931 lookups, to accommodate slow networks and slow hosts.

By default, remote username lookups are not enabled. You can enable
them by editing the Makefile. The remote username lookup timeout period
(30 seconds default) can also be changed by editing the Makefile. The
installation sections below describe the Makefile editing process.

The RFC 931 protocol has diverged into different directions (IDENT and
TAP). To add to the confusion, both protocols use the same network
port.  The daemon wrappers implement a common subset of the protocols.

With TLI-based network services, remote username lookups will be
possible only when TCP/IP is the underlying network protocol.

4.5 - Language extension hooks
------------------------------

The wrappers sport only a limited number of features. This is for a
good reason: programs that are run at high privilege levels must be
easy to verify.

However, some sites have very specific needs.  The options.c file
provides a framework for adding extensions to the access control
language. It comes with sample extensions that:  (1) switch to another
user or group id; (2) perform remote user name lookups; (3) run an
alternate server program (this allows you to produce customized bounce
messages or to do really nasty stuff); (4) set arbitrary environment
variables; (5) change the default file protection mask.

The language extension hook is not enabled by default because it
introduces an incompatible change to the access control language
syntax. Instructions to enable the extensions are given in the
Makefile.

5 - Other works
---------------

5.1 - Related documents
-----------------------

The war story behind the wrapper tools is described in:

    W.Z. Venema, "TCP WRAPPER, network monitoring, access control and
    booby traps", UNIX Security Symposium III Proceedings (Baltimore),
    September 1992.

    ftp.win.tue.nl:/pub/security/tcp_wrapper.ps.Z (postscript)
    ftp.win.tue.nl:/pub/security/tcp_wrapper.txt.Z (flat text)

The same cracker is also described in:

    W.R. Cheswick, "An Evening with Berferd, In Which a Cracker is
    Lured, Endured, and Studied", Proceedings of the Winter USENIX
    Conference (San Francisco), January 1992.

    research.att.com:/dist/internet_security/berferd.ps

5.2 - Related software
----------------------

Network daemons etc. with enhanced logging capabilities can generate
massive amounts of information: our 100+ workstations generate several
hundred kbytes each day. egrep-based filters can help to suppress some
of the noise.  A more powerful tool is the Swatch monitoring system by
Stephen E. Hansen and E. Todd Atkins. Swatch can process log files in
real time and can associate arbitrary actions with patterns; its
applications are by no means restricted to security.  Swatch is
available from sierra.stanford.edu, directory /pub/sources.

Socks, described in the UNIX Security III proceedings, can be used to
control network traffic from hosts on an internal network, through a
firewall host, to the outer world. Socks consists of a daemon that is
run on the firewall host, and of a library with routines that redirect
application socket calls through the firewall daemon.  Socks is
available from s1.gov in /pub/socks.tar.Z.

Tcpr is a set of perl scripts by Paul Ziemba that enable you to run ftp
and telnet commands across a firewall. Unlike socks it can be used with
unmodified client software. Available from ftp.alantec.com, pub/tcpr.

Versions of rshd and rlogind, modified to report the remote user name
in addition to the remote host name, are available for anonymous ftp
(ftp.win.tue.nl:/pub/security/logdaemon-2.tar.Z).  These programs are
drop-in replacements for SunOS 4.x, Ultrix 4.x, and SunOS 5.x.

The securelib shared library by William LeFebvre can be used to control
access to network daemons that are not run under control of the inetd
or that serve more than one client, such as the NFS mount daemon that
runs until the machine goes down.  Available from eecs.nwu.edu, file
/pub/securelib.tar.

xinetd (posted to comp.sources.unix) is an inetd replacement program
that provides, among others, logging, username lookup and access
control. However, it does not support TLI services, and it is only six
times as much source code as the daemon wrapper programs.

Where shared libraries or router-based packet filtering are not an
option, an alternative portmap daemon can help to improve RPC security,
in particular that of NFS and of the NIS (YP) information service.
ftp.win.tue.nl:/pub/security/portmap.shar.Z was tested with SunOS 4.1.1
and 4.1.2, Ultrix 3.0 and Ultrix 4.x, HP-UX 8.x and AIX. The protection
is less effective than that of the securelib library because portmap is
mostly a dictionary service.  SunOS 4.x users should install the latest
revision of the portmap and NIS daemons instead, or adopt NIS+ which
has access control built in.

Source for a portable RFC 931 (TAP, IDENT)-compatible daemon by Peter
Eriksson is available from ftp.lysator.liu.se:/pub/ident/servers.

Some TCP/IP implementations come without syslog library. Some come with
the library but have no syslog daemon. A replacement can be found in
ftp.win.tue.nl:/pub/security/surrogate-syslog.tar.Z.  The fakesyslog
library that comes with the nntp sources reportedly works well, too.

6 - Limitations
---------------

6.1 - Known wrapper limitations
-------------------------------

Some UDP (and rpc/udp) daemons linger around for a while after they
have serviced a request, just in case another request comes in.  In the
inetd configuration file these daemons are registered with the `wait'
option. Only the request that started such a daemon will be seen by the
wrappers.  Such daemons are better protected with the securelib shared
library (see: Related software).

The wrappers do not work with RPC services over TCP. These services are
registered as rpc/tcp in the inetd configuration file. The only non-
trivial service that is affected by this limitation is rexd, which is
used by the on(1) command. This is no great loss.  On most systems,
rexd is less secure than a wildcard in /etc/hosts.equiv.

RPC broadcast requests (for example: rwall, rup, rusers) always appear
to come from the responding host. What happens is that the client
broadcasts its request to all portmap daemons on its network; each
portmap daemon forwards the request to its own system. As far as the
rwall etc.  daemons know, the request comes from the local host.

Portmap and RPC (e.g. NIS and NFS) (in)security is a topic in itself.
See the section in this document on related software.

6.2 - Known system software bugs
--------------------------------

Workarounds have been implemented for several bugs in system software.
They are described in the Makefile. Unfortunately, some system software
bugs cannot be worked around. The result is loss of functionality.

Older ConvexOS versions come with a broken recvfrom(2) implementation.
This makes it impossible for the daemon wrappers to look up the
remote host address (and hence, the name) in case of UDP requests.
A patch is available for ConvexOS 10.1; later releases should be OK.

On some systems, the optional RFC 931 remote username lookups may
trigger a kernel bug.  When a client host connects to your system, and
the RFC 931 connection from your system to that client is rejected by a
router, your kernel may drop all connections with that client.  This is
not a bug in the wrapper programs: complain to your vendor, and don't
enable remote user name lookups until the bug has been fixed.

Reportedly, SunOS 4.1.1, Next 2.0a, ISC 3.0 with TCP 1.3, and AIX 3.2.2
are OK.

Sony News/OS 4.51, HP-UX 8-something and Ultrix 4.3 still have the bug.
At the time of writing, a fix for Ultrix is being field tested (CXO-8919).

The following procedure can be used (from outside the tue.nl domain) to
find out if your kernel has the bug. From the system under test, do:

    % ftp 131.155.70.100

This command attempts to make an ftp connection to our anonymous ftp
server (ftp.win.tue.nl).  When the connection has been established, run
the following command from the same system under test, while keeping
the ftp connection open:

    % telnet 131.155.70.100 111

Do not forget the `111' at the end of the command. This telnet command
attempts to connect to our portmap process.  The telnet command should
fail with:  "host not reachable", or something like that. If your ftp
connection gets messed up, you have the bug. If the telnet command does
not fail, please let me know a.s.a.p.!

For those who care, the bug is that the BSD kernel code was not careful
enough with incoming ICMP UNREACHABLE control messages (it ignored the
local and remote port numbers). The bug is still present in the BSD
NET/1 source release (1989) but apparently has been fixed in BSD NET/2
(1991). You can see it with your own eyes, if you have the courage.

7 - Configuration and installation
----------------------------------

7.1 - Easy configuration and installation
-----------------------------------------

The "easy" recipe requires no changes to existing software or
configuration files.  Basically, you move the daemons that you want to
protect to a different directory and plug the resulting holes with
copies of the wrapper programs.

If you don't run Ultrix, you won't need the miscd wrapper program.  The
miscd daemon implements among others the SYSTAT service, which produces
the same output as the the WHO command.

Copy the file Makefile.dist to Makefile, edit the Makefile according to
the instructions at the beginning of that file, and type `make'.

When the `make' succeeds the result is two executables (maybe three in
case of Ultrix). The `try' program can be used to play with host access
control tables and is described in a later section.

The tcpd program can be used to monitor the telnet, finger, ftp, exec,
rsh, rlogin, tftp, talk, comsat and other tcp or udp services that have
a one-to-one mapping onto executable files.

The tcpd program can also be used for services that are marked as
rpc/udp in the inetd configuration file, but not for rpc/tcp services
such as rexd.  You probably do not want to run rexd anyway. On most
systems it is even less secure than a wildcard in /etc/hosts.equiv.

With System V.4-style systems, the tcpd program can also handle TLI
services. When TCP/IP or UDP/IP is used underneath TLI, the wrappers
provide the same functions as with socket-based applications. When some
other protocol is used underneath TLI, functionality will be limited
(no remote username lookups, weird network address formats).

Decide which services you want to monitor. Move the corresponding
vendor-provided daemon programs to the location specified by the
REAL_DAEMON_DIR constant in the Makefile, and fill the holes with
copies of the tcpd wrapper. That is, one copy of (or link to) the tcpd
program for each service that you want to monitor. For example, to
monitor the use of your finger service:

    # mkdir REAL_DAEMON_DIR
    # mv /usr/etc/in.fingerd REAL_DAEMON_DIR
    # cp tcpd /usr/etc/in.fingerd

The example applies to SunOS 4. With other UNIX implementations the
network daemons live in /usr/libexec or /usr/sbin, or have no "in."
prefix to their names, but you get the idea.

Ultrix only:  If you want to monitor the SYSTAT service, move the
vendor-provided miscd daemon to the location specified by the
REAL_MISCD macro in the Makefile, and install the miscd wrapper into
the original miscd location.

In the absence of any access-control tables, the daemon wrappers
will just maintain a record of network connections made to your system.

7.2 - Advanced configuration and installation
---------------------------------------------

The advanced recipe leaves your daemon executables alone, but involves
simple modifications to the inetd configuration file.

Copy the file Makefile.dist to Makefile.  In the Makefile, define the
REAL_DAEMON_DIR macro (if you run Ultrix, the REAL_MISCD macro, too) to
reflect the path to your existing network daemons. Don't panic when
some daemons live elsewhere; we'll deal with that later.  Have a look
at the other instructions in the Makefile and type `make'.

When the `make' succeeds the result is two executables (maybe three in
case of Ultrix). The `try' program can be used to play with host access
control tables and is described in a later section.

The tcpd program can be used to monitor the telnet, finger, ftp, exec,
rsh, rlogin, tftp, talk, comsat and other tcp or udp services that have
a one-to-one mapping onto executable files.

With System V.4-style systems, the tcpd program can also handle TLI
services. When TCP/IP or UDP/IP is used underneath TLI, the wrappers
provide the same functions as with socket-based applications. When some
other protocol is used underneath TLI, functionality will be limited
(no remote username lookups, weird network address formats).

The tcpd program can also be used for services that are marked as
rpc/udp in the inetd configuration file, but not for rpc/tcp services
such as rexd.  You probably do not want to run rexd anyway. On most
systems it is even less secure than a wildcard in /etc/hosts.equiv.

Install the tcpd command in a suitable place. Apollo UNIX users will
want to install it under a different name because the name "tcpd" is
already taken; a suitable name for the wrapper program would be
"frontd".  Then perform the following edits on the inetd configuration
file (usually /etc/inetd.conf or /etc/inet/inetd.conf):

    finger  stream  tcp     nowait  nobody  /usr/etc/in.fingerd     in.fingerd

becomes:

    finger  stream  tcp     nowait  nobody  /usr/etc/tcpd           in.fingerd

Send a `kill -HUP' to the inetd process to make the change effective.

The example applies to SunOS 4. With other UNIX implementations the
network daemons live in /usr/libexec or /usr/sbin, the network daemons
have no "in." prefix to their names, or the username field in the inetd
configuration file may be missing.

When the finger service works as expected you can perform similar
changes for other network services. Do not forget the `kill -HUP'.

The miscd daemon that comes with Ultrix implements several network
services. It decides what to do by looking at its process name. One of
the services is systat, which is a kind of limited finger service.  If
you want to monitor the systat service, install the miscd wrapper in
a suitable place and update the inetd configuration file:

    systat  stream  tcp     nowait  /suitable/place/miscd      systatd

Ultrix 4.3 allows you to specify a user id under which the daemon will
be executed. This feature is not documented in the manual pages.  Thus,
the example would become:

    systat  stream  tcp     nowait  nobody /suitable/place/miscd    systatd

Older Ultrix systems still run all their network daemons as root.

In the absence of any access-control tables, the daemon wrappers
will just maintain a record of network connections made to your system.

7.3 - Daemons with arbitrary path names
---------------------------------------

The above tcpd examples work fine with network daemons that live in a
common directory, but sometimes that is not practical. Having soft
links all over your file system is not a clean solution, either.

Instead you can specify, in the inetd configuration file, an absolute
path name for the daemon process name.  For example,

    ntalk   dgram   udp     wait    root    /usr/etc/tcpd /usr/local/lib/ntalkd

When the daemon process name is an absolute path name, tcpd ignores the
value of the REAL_DAEMON_DIR constant, and uses the last path component
of the daemon process name for logging and for access control.

7.4 - Building and testing the access control rules
---------------------------------------------------

In order to support access control the wrappers must be compiled with
the -DHOSTS_ACCESS option. The access control policy is given in the
form of two tables (default: /etc/hosts.allow and /etc/hosts.deny).
Access control is disabled when there are no access control tables, or
when the tables are empty.

If you haven't used the wrappers before I recommend that you first run
them a couple of days without any access control restrictions. The
logfile records should give you an idea of the process names and of the
host names that you will have to build into your access control rules.

The syntax of the access control rules is documented in the file
hosts_access.5, which is in `nroff -man' format. This is a lengthy
document, and no-one expects you to read it right away from beginning
to end.  Instead, after reading the introductory section, skip to the
examples at the end so that you get a general idea of the language.
Then you can appreciate the detailed reference sections near the
beginning of the document.

The examples in the hosts_access.5 document show two specific types of
access control policy:  1) mostly closed (only permitting access from a
limited number of systems) and 2) mostly open (permitting access from
everyone except a limited number of trouble makers). You will have to
choose what model suits your situation best. Implementing a mixed
policy should not be overly difficult either.

The `try' command can be used to try out your local access control
files.  The command syntax is:

    ./try process_name hostname    (e.g.: ./try in.tftpd localhost)

    ./try process_name address    (e.g.: ./try in.tftpd 127.0.0.1)

In order to find out what process name to use, just use the service and
watch the process name that shows up in the logfile.  Alternatively,
you can look up the name from the inetd configuration file. Coming back
to the tftp example in the tutorial section above:

    tftp  dgram  udp  wait  root  /usr/etc/tcpd  in.tftpd -s /tftpboot

This entry causes the inetd to run the wrapper program (tcpd) with a
process name `in.tftpd'.  This is the name that the wrapper will use
when scanning the access control tables. Therefore, `in.tftpd' is the
process name that should be given to the `try' command. On your system
the actual inetd.conf entry may differ (tftpd instead of in.tftpd, and
no `root' field), but you get the idea.

When you specify a host name, the `try' program will use both the host
name and address. This way you can simulate the most common case where
the wrappers know both the host address and the host name.  The `try'
program will iterate over all addresses that it can find for the given
host name.

When you specify a host address instead of a host name, the `try'
program will pretend that the host name is unknown, so that you can
simulate what happens when the wrapper is unable to look up the remote
host name.

Serious errors in the configuration file syntax will be reported via
the syslog daemon.  Run a `tail -f' on the logfile while playing with
the `try' command. The tutorial section at the beginning of this file
describes where to look for your logfile.

7.5 - Other applications
------------------------

The access control routines can easily be integrated with other
programs.  The hosts_access.3 manual page (`nroff -man' format)
describes the external interface of the libwrap.a library.

The tcpd wrapper can even be used to control access to the smtp port.
In that case, sendmail should not be run as a stand-alone daemon, but
it should be registered in the inetd configuration file. For example:

    smtp    stream  tcp     nowait  root    /usr/etc/tcpd /usr/lib/sendmail -bs

You will periodically want to run sendmail to process queued-up
messages. A crontab entry like:

    0,15,30,45 * * * * /usr/lib/sendmail -q

should take care of that. When you are going to "protect" your sendmail
daemon this way, you should realize that there are many "unprotected"
sendmail daemons all over the network that can still be abused.

8 - Acknowledgements
--------------------

Many people contributed to the evolution of the programs, by asking
inspiring questions, by suggesting features or bugfixes, or by
submitting source code.  Nevertheless, all mistakes and bugs in the
wrappers are my own.

Thanks to Brendan Kehoe ([e-mail]), Heimir Sverrisson
([e-mail]) and Dan Bernstein ([e-mail]) for
feedback on an early release of this product.  The host name/address
check was suggested by John Kimball ([e-mail]).
Apollo's UNIX environment has some peculiar quirks: Willem-Jan Withagen
([e-mail]), Pieter Schoenmakers ([e-mail]) and
Charles S. Fuller ([e-mail]) provided assistance.  Hal R.
Brand ([e-mail]) told me how to get the remote IP address
in case of datagram-oriented services, and suggested the optional shell
command feature.  Shabbir Safdar ([e-mail]) provided
a first version of a much-needed manual page.  Granville Boman Goza, IV
([e-mail]) suggested to use the remote IP address even when the
host name is available.  Casper H.S. Dik ([e-mail]) provided
additional insight into DNS spoofing techniques.  The bogus daemon
feature was inspired by code from Andrew Macpherson (BNR Europe Ltd).
Steve Bellovin ([e-mail]) confirmed some of my suspicions
about the darker sides of TCP/IP insecurity.

In no particular order, Howard Chu ([e-mail]), John P.
Rouillard ([e-mail]), Darren Reed ([e-mail]),
Icarus Sparry ([e-mail]), Scott Schwartz (schwartz@
cs.psu.edu), John A. Kunze ([e-mail]), Daniel Len
Schales ([e-mail]), Chris Turbeville <[e-mail]>,
Paul Kranenburg <[e-mail]>, and many, many others provided
fixes, code fragments, or other improvements to the wrappers.

    Wietse Venema ([e-mail])
    Department of Mathematics and Computing Science
    Eindhoven University of Technology
    P.O. Box 513
    5600 MB Eindhoven
    The Netherlands